-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed element access expression writes for divergent write types #55585
Fixed element access expression writes for divergent write types #55585
Conversation
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
@@ -7239,8 +7239,8 @@ export function isRightSideOfQualifiedNameOrPropertyAccess(node: Node) { | |||
|
|||
/** @internal */ | |||
export function isRightSideOfAccessExpression(node: Node) { | |||
return isPropertyAccessExpression(node.parent) && node.parent.name === node | |||
|| isElementAccessExpression(node.parent) && node.parent.argumentExpression === node; | |||
return !!node.parent && (isPropertyAccessExpression(node.parent) && node.parent.name === node |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other utils like this one do not have a guard like this so it looks a little bit off. However, .parent
is actually nullable - a SourceFile
doesn't have a parent. I could guard this before calling this function but personally, I prefer to have it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
those tests are borrowed from #54777 , just adjusted to use the element access expressions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
most of the test cases here (but not all) are borrowed from tests/cases/compiler/divergentAccessorsTypes1-6.ts
u1['prop1'] = 42; | ||
u1['prop1'] = "hello"; | ||
|
||
u1['prop2'] = 42; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that this one should error. See the playground here
I re-verified all of the tests here and everything here behaves in the same way as it behaves for regular property access expressions. So I think that this issue is a separate one and I will try to prepare a follow up PR to fix it.
Will this break cases where (I have seen people use this to be able to access private properties in test files without completely turning off ts type check for the line.) |
It's definitely intended to be just about the writable part. If you have any complete example of what you have in mind in regards to private properties then I could take a look at it and re-verify that I don't break something that shouldn't be broken. |
Here is one example :) export class ExampleClass {
private name = 'Name';
}
const example = new ExampleClass();
const accessedName = example['name']; |
I don't think this will be affected by this PR |
@typescript-bot test top200 |
Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at 46e771a. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at 46e771a. You can monitor the build here. Update: The results are in! Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at 46e771a. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the regular perf test suite on this PR at 46e771a. You can monitor the build here. Update: The results are in! |
@jakebailey Here are the results of running the user test suite comparing There were infrastructure failures potentially unrelated to your change:
Otherwise... Everything looks good! |
@jakebailey Here they are:
CompilerComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
StartupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
Hey @jakebailey, it looks like the DT test run failed. Please check the log for more details. |
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
Hey @jakebailey, it looks like the DT test run failed. Please check the log for more details. |
@typescript-bot run dt |
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at 46e771a. You can monitor the build here. Update: The results are in! |
Hey @jakebailey, the results of running the DT tests are ready. |
I noticed this problem yesterday when working on #55576
The problem is that those two should always behave in the same way and they should use the same write type: